In traditional continuous integration systems, contributors typically pull a recent (preferably latest) stable project version into a private workspace, develop their changesets, perform a set of mandatory pre-commit quality verifications (build, unit test, static analysis, etc.), update their workspace to the now latest project version thus integrating (merging) their changeset with other changesets committed on the project branch after the stable project version used in their workspace, eventually repeat the pre-commit quality verifications depending on the complexity and risk of the update to the latest project version and finally commit the code to the branch thus creating a new latest project version. Periodically (or even after every commit), automated tasks perform a set of integration quality verifications on the latest or a recent project version to detect regressions in the software quality.
Occasionally the detected quality regressions are catastrophic in the sense that they are build or test failures which would prevent some or all branch contributors with workspaces based on the respective project version from successfully passing the set of mandatory pre-commit quality verifications and thus from committing their changesets. The project versions affected by such quality regressions are considered unstable. Quality regressions causing unstable project versions need to be addressed for the project as a whole to move forward and are therefore considered blocking regressions.
Addressing blocking regressions are not time-bound, typically because they may require human intervention for investigation and/or fixing, or because multiple simultaneous quality regressions may mask each other necessitating multiple sequential iterations until stability is achieved.
Changesets causing blocking regressions fall into two categories: faulty changesets which cause quality regressions by themselves, and conflicting changesets which by themselves don't cause quality regressions but do so when integrated together.
The probability of blocking regressions caused by faulty changesets increases with the increase of the project branch commit rate. The probability of blocking regressions caused by conflicting changesets increases with the number of outstanding individual changesets which are committed after the stable branch label used in the individual contributor workflows and which are thus not included in the workflow quality verification context. The number of these outstanding changesets increases with the number of unstable labels, the time required to address the blocking regressions causing the instabilities, and with the project branch commit rate.
Eventually, as the branch commit rate increases, the probability of obtaining stable labels decreases until it eventually reaches insignificant levels, effectively bringing the project to a halt. The limited achievable branch commit rate makes traditional continuous integration systems unattractive for larger scale projects.
This background information is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art or forms part of the general common knowledge in the relevant art.